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Requirements for a 
Domainkeys Identified Mail (DKIM) Signing Practices Protocol 


Status of This Memo 


This memo provides information for the Internet community. It does 


not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


Domainkeys Identified Mail (DKIM) provides a cryptographic mechanism 
for domains to assert responsibility for the messages they handle. A 
related mechanism will allow an administrator to publish various 
statements about their DKIM signing practices. This document defines 
requirements for this mechanism, distinguishing between those that 


must be satisfied (MUST), and those that are highly desirable 
(SHOULD) . 
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1. Introduction 


Domainkeys Identified Mail [RFC4871] defines a message level signing 
and verification mechanism for email. While a DKIM signed message 
speaks for itself, there is ambiguity if a message doesn’t have a 
valid first party signature (i.e., on behalf of the [RFC2822].From 
address): is this to be expected or not? For email, this is an 
especially difficult problem since there is no expectation of a 
priori knowledge of a sending domain’s practices. This ambiguity can 
be used to mount a bid down attack that is inherent with systems like 
email that allow optional authentication: if a receiver doesn’t know 
otherwise, it should not assume that the lack of a valid signature is 
exceptional without other information. Thus, an attacker can take 
advantage of the ambiguity and simply not sign messages. If a 
protocol could be developed for a domain to publish its DKIM signing 
practices, a message verifier could take that into account when it 
receives an unsigned piece of email. 
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This document defines the requirements for a mechanism that permits 
the publication of Sender Signing Practices (SSP). The document is 
organized into two main sections: first, a Problem and Deployment 
Scenario section that describes the problems that SSP is intended to 
address as well as the deployment issues surrounding the base 
problems, and the second section is the Requirements that arise 
because of those scenarios. 


2. Definitions and Requirements Language 


o Domain Holder: the entity that controls the contents of the DNS 
subtree starting at the domain, either directly or by delegation 
via NS records it controls. 


o First Party Address: for DKIM, a first party address is defined to 
be the [RFC2822].From address in the message header; a first party 
address is also known as an Author address. 


o First Party Signature: a first party signature is a valid 
signature where the signing identity (the d= tag or the more 
specific identity i= tag) matches the first party address. 
"Matches" in this context is defined in [RFC4871]. 


o Third Party Signature: a third party signature is a valid 
signature that does not qualify as a first party signature. Note 
that a DKIM third party signature is not required to correspond to 
a header field address such as the contents of Sender or List-—Id, 
etc. 


o Practice: a statement according to the [RFC2822].From domain 
holder of externally verifiable behavior in the email messages it 
sends. 


o Expectation: an expectation combines with a practice to convey 
what the domain holder considers the likely survivability of the 
practice for a receiver, in particular receivers that may be more 
than one SMTP hop away. 


o DKIM Signing Complete: a practice where the domain holder asserts 
that all legitimate mail will be sent with a valid first party 
signature. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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SSP Problem Scenarios 


The email world is a diverse place with many deployment 
considerations. This section outlines expected usage scenarios where 
DKIM signing/verifying will take place, and how a new protocol might 
help to clarify the relevance of DKIM-signed mail. 


1. Problem Scenario 1: Is All Mail Signed with DKIM? 


After auditing their outgoing mail and deploying DKIM signing for all 
of their legitimate outgoing mail, a domain could be said to be DKIM 
signing complete. That is, the domain has, to the best of its 
ability, ensured that all legitimate mail purporting to have come 
from that domain contains a valid DKIM signature. 


A receiver in the general case doesn’t know what the practices are 
for a given domain. Thus, the receiver is at a disadvantage in not 
knowing whether or not it should expect all mail to be signed from a 
given domain. This knowledge gap leads to a trivially exploitable 
bid-down attack where the attacker merely sends unsigned mail; since 
the receiver doesn’t know the practices of the signing domain, it 
cannot treat the message any more harshly for lack of a valid 
signature. 


An information service that allows a receiver to query for the 
practices and expectations of the first party domain when no valid 
first party signature is found could be useful in closing this gap. 

A receiver could use this information to treat such questionable mail 
with varying degrees of prejudice. 


Note that, for the foreseeable future, unrestricted use patterns of 
mail (e.g., where users may be members of mailing lists, etc.) will 
likely suffer occasional, non-malicious signature failure in transit. 
While probably not a large percentage of total traffic, this kind of 
breakage may be a significant concern for those usage patterns. This 
scenario defines where the sender cannot set any expectation as to 
whether an individual message will arrive intact. 


Even without that expectation, a receiver may be able to take 
advantage of the knowledge that the domain’s practice is to sign all 
mail and bias its filters against unsigned or damaged in transit 
mail. This information should not be expected to be used in a binary 
yes/no fashion, but instead as a data point among others ina 
filtering system. 
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The following exchange illustrates problem scenario 1. 


1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 
with a missing or broken DKIM first party signature from Alice. 


2. Domain Bob would like to know whether that is an expected state 
of affairs. 


3. Domain Alice provides information that it signs all outgoing 
mail, but places no expectation on whether it will arrive with an 
intact first party signature. 


4. Domain Bob could use this information to bias its filters to 
examine the message with some suspicion. 


3.2. Problem Scenario 2: Illegitimate Domain Name Use 


A class of mail typified by transactional mail from high-value 
domains is currently the target of phishing attacks. In particular, 
many phishing scams forge the [RFC2822].From address in addition to 
spoofing much of the content to trick unsuspecting users into 
revealing sensitive information. Domain holders sending this mail 
would like the ability to give an enhanced guarantee that mail sent 
with their domain name should always arrive with the proof that the 
domain holder consented to its transmission. That is, the message 
should contain a valid first party signature as defined above. 


From a receiver’s standpoint, knowing that a domain not only signs 
all of its mail, but places a very high value on the receipt of a 
valid first party signature from that domain is helpful. Hence, a 
receiver knows that the sending domain signs all its mail, and that 
the sending domain considers mail from this domain particularly 
sensitive in some sense, and is asking the receiver to be more 
suspicious than it otherwise might be of a broken or missing first- 
party signature. A receiver with the knowledge of the sender’s 
expectations in hand might choose to process messages not conforming 
to the published practices in a special manner. Note that the 
ability to state an enhanced guarantee of a valid signature means 
that senders should expect mail that traverses modifying 
intermediaries (e.g., mailing lists, etc.) will likely be quarantined 
or deleted; thus, this scenario is more narrow than problem scenario 
Ty 


Informative Note: a receiving filter may choose to treat scenario 
2 much more harshly than scenario 1; where scenario 1 looks odd, 
scenario 2 looks like something is very wrong. 
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1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 
with a missing or broken first party DKIM signature from domain 
Alice. 


2. Domain Bob would like to know whether that is an expected state 
of affairs. 


3. Domain Alice provides information that it signs all outgoing 
mail, and furthermore places an expectation that it should arrive 
with an intact first party signature, and that the receiver 
should be much more wary if it does not. 


4. Domain Bob could use this information to bias its filters such 
that it examines the message with great suspicion. 


4. SSP Deployment Considerations 
Given the problems enumerated above for which we’d like SSP to 
provide information to recipients, there are a number of scenarios 
that are not related to the problems that are to be solved, per se, 
but the actual mechanics of implementing/deploying the information 
service that SSP would provide. 


4.1. Deployment Consideration 1: Outsourced Signing 


Many domains do not run their own mail infrastructure, or may 


outsource parts of it to third parties. It is desirable for a domain 
holder to have the ability to delegate to other entities the ability 
to sign for the domain holder. One obvious use scenario is a domain 


holder from a small domain that needs to have the ability for their 
outgoing ISP to sign all of their mail on behalf of the domain 
holder. Other use scenarios include outsourced bulk mail for 
marketing campaigns, as well as outsourcing various business 
functions, such as insurance benefits, etc. 


4.2. Deployment Consideration 2: Subdomain Coverage 


An SSP client will perform lookups on incoming mail streams to 
provide the information as proposed in the problem scenarios. The 
domain part of the first address of the [RFC2822].From will form the 
basis to fetch the published information. A trivial attack to 
circumvent finding the published information can be mounted by simply 
using a subdomain of the parent domain that doesn’t have published 
information. This attack is called the subdomain attack: that is, a 
domain wants to not only publish a policy for a given DNS label it 
controls, but it would also like to protect all subdomains of that 
label as well. If this characteristic is not met, an attacker would 
need only create a possibly fictitious subdomain that was not covered 


Thomas Informational [Page 6] 


RFC 5016 DKIM-SSP-REQ October 2007 


by the SSP’s information service. Thus, it would be advantageous for 
SSP to not only cover a given domain, but all subdomains of that 
domain as well. 


4.3. Deployment Consideration 3: Resent Original Mail 


Resent mail is a common occurrence in many scenarios in the email 
world of today. For example, domain Alice sends a DKIM-signed 
message with a published practice of signing all messages to domain 
Bob’s mailing list. Bob, being a good net citizen, wants to be able 
to take his part of the responsibility of the message in question, so 
he DKIM signs the message, perhaps corresponding to the Sender 
address. 


Note that this scenario is completely orthogonal to whether Alice’s 
signature survived Bob’s mailing list: Bob merely wants to assert his 
part in the chain of accountability for the benefit of the ultimate 
receivers. It would be useful for this practice to be encouraged as 
it gives a more accurate view of who handled the message. It also 
has the side benefit that remailers that break DKIM first party 
signatures can be potentially assessed by the receiver based on the 
receiver’s opinion of the signing domains that actually survived. 


4.4. Deployment Consideration 4: Incremental Deployment of Signing 


As a practical matter, it may be difficult for a domain to roll out 
DKIM signing such that they can publish the DKIM Signing Complete 
practice given the complexities of the user population, the 
outsourced vendors sending on its behalf, etc. This leaves open an 
exploit that high-value mail, such as in Problem Scenario 2, must be 
classified to the least common denominator of the published 
practices. It would be desirable to allow a domain holder to publish 
a list of exceptions that would have a more restrictive practices 
statement. NB: this consideration has been deemed met by the 
mechanisms provided by the base DKIM signing mechanism; it is merely 
documented here as having been an issue. 


For example, bigbank.example.com might be ready to say that 
statements@bigbank.example.com is always signed, but the rest of the 
domain, say, is not. Another situation is that the practices of some 
address local parts in a given domain are not the same as practices 
of other local parts. Using the same example of 
statements@bigbank.example.com being a transactional kind of email 
that would like to publish very strong practices, mixed in with the 
rest of the user population local parts, which may go through mailing 
lists, etc., for which a less strong statement is appropriate. 
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It should be said that DKIM, through the use of subdomains, can 
already support this kind of differentiation. That is, in order to 
publish a strong practice, one only has to segregate those cases into 
different subdomains. For example: accounts.bigbank.example.com 
would publish constrained practices, while 
corporateusers.bigbank.example.com might publish more permissive 
practices. 


4.5. Deployment Consideration 5: Performance and Caching 


Email service provides an any-any mesh of potential connections: all 
that is required is the publication of an MX record and an SMTP 
listener to receive mail. Thus, the use of SSP is likely to fall 
into two main scenarios, the first of which are large, well-known 
domains that are in constant contact with one another. In this case, 
caching of records is essential for performance, including the 
caching of the non-existence of records (i.e., negative caching). 


The second main scenario is when a domain exchanges mail with a much 
smaller volume domain. This scenario can be both perfectly normal as 
with the case of vanity domains, and unfortunately, a vector for 
those sending mail for anti-social reasons. In this case, we’d like 
the message exchange burden to SSP querier to be low, since many of 
the lookups will not provide a useful answer. Likewise, it would be 
advantageous to have upstream caching here as well so that, say, a 
mailing list exploder on a small domain does not result in an 
explosion of queries back at the root and authoritative server for 
the small domain. 


4.6. Deployment Consideration 6: Human Legibility of Practices 


While SSP records are likely to be primarily consumed by an 
automaton, for the foreseeable future they are also likely to be 
inspected by hand. It would be nice to have the practices stated in 
a fashion that is also intuitive to the human inspectors. 


4.7. Deployment Consideration 7: Extensibility 
While this document pertains only to requirements surrounding DKIM 
signing practices, it would be beneficial for the protocol to be able 
to extend to other protocols. 

4.8. Deployment Consideration 8: Security 
SSP must be able to withstand life in a hostile, open-Internet 
environment. These include DoS attacks, and especially DoS attacks 


that leverage themselves through amplification inherent in the 
protocol. In addition, while a useful protocol may be built without 
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strong source authentication provided by the information service, a 
path to strong source authentication should be provided by the 
protocol, or underlying protocols. 


5. Requirements 


This section defines the requirements for SSP. As with most 
requirements documents, these requirements define the MINIMUM 
requirements that a candidate protocol must provide. It should also 
be noted that SSP must fulfill all of the requirements. 


5.1. Discovery Requirements 


Receivers need a means of obtaining information about a sender’s DKIM 
practices. This requires a means of discovering where the 
information is and what it contains. 


1. The author is the first-party sender of a message, as specified 
in the [RFC2822].From field. SSP’s information is associated 
with the author’s domain name, and is published subordinate to 
that domain name. 


2. In order to limit the cost of its use, any query service 
supplying SSP’s information MUST provide a definitive response 
within a small, deterministic number of message exchanges under 
normal operational conditions. 


Informative Note: this, for all intents and purposes is a 
prohibition on anything that might produce loops or result in 
extended delays and overhead; also though "deterministic" 
doesn’t specify how many exchanges, the expectation is "few". 


Refs: Deployment Considerations, Sections 4.2 and 4.5. 
3. SSP’s publishing mechanism MUST be defined such that it does not 


lead to multiple resource records of the same type for different 
protocols residing at the same location. 


Informative note: an example is multiple resource record of the 
same type within a common DNS leaf. Hence, uniquely defined 
leaf names or uniquely defined resource record types will 
ensure unambiguous referencing. 


Refs: Deployment Consideration, Section 4.2. 
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4. SSP retrieval SHOULD provide coverage for not only a given domain 
but all of its subdomains as well. It is recognized that there 
is some reasonable doubt about the feasibility of a widely 
accepted solution to this requirement. If the working group does 
not achieve rough consensus on a solution, it MUST document the 
relevant security considerations in the protocol specification. 


Refs: Deployment Considerations, Sections 4.2 and 4.5. 
5.2. SSP Transport Requirements 
The publication and query mechanism will operate as an internet-based 
message exchange. There are multiple requirements for this lower- 
layer service: 
1. The exchange SHOULD have existing widespread deployment of the 


transport layer, especially if riding on top of a true transport 
layer (e.g., TCP, UDP). 


Refs: Deployment Considerations, Sections 4.5 and 4.7. 
2. The query/response in terms of latency time and the number of 
messages involved MUST be low (less than three message exchanges 


not counting retransmissions or other exceptional conditions). 


Refs: Deployment Consideration, Section 4.5. 


3. If the infrastructure doesn’t provide caching (a la DNS), the 
records retrieved MUST provide initiators the ability to maintain 
their own cache. The existing caching infrastructure is, 
however, highly desirable. 


Refs: Deployment Consideration, Section 4.5. 


4. Multiple geographically and topologically diverse servers MUST be 
supported for high availability. 


Refs: Deployment Considerations, Sections 4.5 and 4.7. 
5.3. Practice and Expectation Requirements 


As stated in the definitions section, a practice is a statement 
according to the [RFC2822].From domain holder of externally 
verifiable behavior in the email messages it sends. As an example, a 
practice might be defined such that all email messages will contain a 
DKIM signature corresponding to the [RFC2822].From address. Since 
there is a possibility of alteration between what a sender sends and 
a receiver examines, an expectation combines with a practice to 
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convey what the [RFC2822].From domain considers the likely outcome of 
the survivability of the practice at a receiver. For example, a 
practice that a valid DKIM for the [RFC2822].From address is present 
when it is sent from the domain, and an expectation that it will 
remain present and valid for all receivers whether topologically 
adjacent or not. 


1. SSP MUST be able to make practices and expectation assertions 
about the domain part of a [RFC2822].From address in the context 
of DKIM. SSP will not make assertions about other addresses for 
DKIM at this time. 


Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 


2. SSP MUST provide a concise linkage between the [RFC2822].From and 
the identity in the DKIM i= tag, or its default if it is missing 
in the signature. That is, SSP MUST precisely define the 
semantics of what qualifies as a first party signature. 


Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 

3. SSP MUST be able to publish a practice that the domain’s signing 
behavior is "DKIM Signing Complete". That is, all messages were 
transmitted with a valid first party signature. 

Refs: Problem Scenario 1, Section 3.1. 

4. SSP MUST be able to publish an expectation that a verifiable 
first party DKIM signature should be expected on receipt of a 
message. 

Refs: Problem Scenario 2, Section 3.2. 
5. Practices and expectations MUST be presented in SSP syntax using 


as intuitive a descriptor as possible. For example, p=? would be 
better represented as p=unknown. 


Refs: Deployment Consideration, Section 4.6. 


6. Because DKIM uses DNS to store selectors, there is always the 
ability for a domain holder to delegate all or parts of the 
_domainkey subdomain to an affiliated party of the domain 
holder’s choosing. That is, the domain holder may set an NS 
record for _domainkey.example.com to delegate to an email 
provider who manages the entire namespace. There is also the 
ability for the domain holder to partition its namespace into 
subdomains to further constrain third parties. For example, a 
domain holder could delegate only _domainkey.benefits.example.com 
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to a third party to constrain the third party to only be able to 
produce valid signatures in the benefits.example.com subdomain. 
Last, a domain holder can even use CNAME’s to delegate individual 
leaf nodes. Given the above considerations, SSP need not invent 
a different means of allowing affiliated parties to sign ona 
domain’s behalf at this time. 


Refs: Deployment Consideration, Section 4.4. 


Practices and expectations MUST be presented as an information 
service from the signing domain to be consumed as an added factor 
to the receiver’s local policy. In particular, a practice or 
expectation MUST NOT mandate any disposition stance on the 
receiver. 


Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 


There is no requirement that SSP publish practices of any/all 
third parties that MUST NOT sign on the domain holder’s behalf. 
This should be considered out of scope. 


INFORMATIVE NOTE: this is essentially saying that the protocol 
doesn’t have to concern itself with being a blacklist 
repository. 


Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. 


SSP MUST NOT be required to be invoked if a valid first party 
signature is found. 


Refs: Deployment Consideration, Section 4.2. 


SSP MUST NOT provide a mechanism that impugns the existence of 
non-first party signatures in a message. A corollary of this 
requirement is that the protocol MUST NOT link practices of first 
party signers with the practices of third party signers. 


INFORMATIVE NOTE: the main thrust of this requirement is that 
practices should only be published for that which the publisher 
has control, and should not meddle in what is ultimately the 
local policy of the receiver. 


Refs: Deployment Consideration, Section 4.3. 
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4. Extensibility and Forward Compatibility Requirements 


1. SSP MUST NOT extend to any protocol other than DKIM for email at 
this time. SSP SHOULD be extensible for protocols other than 
DKIM. 


Refs: Deployment Consideration, Section 4.7. 


2. SSP MUST be able to add new practices and expectations within the 
existing discovery/transport/practices in a backward compatible 
fashion. 


Refs: Deployment Consideration, Section 4.7. 
Requirements for SSP Security 


1. SSP for a high-value domain is potentially a high-value DoS 
target, especially since the unavailability of SSP’s record could 
make unsigned messages less suspicious. 


2. SSP MUST NOT make highly leveraged amplification or make-work 
attacks possible. In particular, the work and message exchanges 
involved MUST be order of a constant. 


Refs: Deployment Consideration, Section 4.8. 


3. SSP MUST have the ability for a domain holder to provide SSP’s 
data such that a receiver can determine that it is authentically 
from the domain holder with a large degree of certainty. SSP may 
provide means that provide less certainty in trade off for ease 
of deployment. 


Refs: Deployment Consideration, Section 4.8. 
Security Considerations 


This document defines requirements for a new protocol and the 
security related requirements are defined above. Since it is 
expected that the new protocol will use the DNS as a basis for the 
published SSP information, most if not all of the threats described 
in [RFC4686] will be applicable. 
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